
I n previous columns, I have described the features that 
make up multi-user Smalltalk. These features include 
support for transactions, concurrency control and 
locking, versioning and instance migration, and security. 
These are but a few of the features requi red for a Smal Ital k 
system to function as a server. In addition to these fea¬ 
tures, a server Smalltalk system must also provide persis¬ 
tence of objects, fault tolerance, and scalability. This col¬ 
umn is the first of two that describe how multi-user 
Smalltalk fits in the emerging 3-tier architecture, and how 
partitioning Smalltalk applications between clients and 
the server overcomes performance bottlenecks and 
allows the implementation of shared business objects in a 
server Smalltalk environment. 

There are three kinds of objects that exist in a typical 
application: presentation, application, and business ob¬ 
jects. Presentation objects are the widgets, forms, and 
windows that present information to the end user. 
Application objects are the objects responsible for the 
sequencing of tasks and the management of how busi¬ 
ness objects are used by the end user to achieve a specif¬ 
ic task. Business objects are general-purpose objects that 
model the processes and basic concepts of the business. 
Business objects are a hot topic these days, as companies 
undergo business process reengineering to better model 
the basic functions of the company. (See Rymer 1 for a 
detailed discussion of business objects.) There is even a 
Business Object M anagement Special Interest Group that 
was founded bytheOMG. 

When Smalltalk is used as the implementation lan¬ 
guage on the client machine only, the objects that imple¬ 
ment the application and business logic, as well as the 
objects that implement the presentation logic, must all 
reside in the Smalltalk image on the client machine. 
Typically, when the application starts up, it connects to 
either a relational or object database and transfers the 
object state needed to run the application to the client 
machine. If the database is relational, the tabular data in 
the database must be mapped to objects in the image. 
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The appl ication may take advantage of the query capabi I- 
ity of the database to selectively choose which objects are 
manifested in the client. However, to execute any busi¬ 
ness logic, the objects must be present in the client 
Smalltalk image. This is how Smalltalk is used in a pure 
cl i ent/ server arch i tectu re. 

The pure client/server architecture works well on a 
small scale, but has a number of drawbacks that hinder its 
ability to implement enterprise-wide, shared business 
objects. In this architecture, the server does not have the 
ability to execute complex business logic. The database 
may provide some query capability or stored procedures, 
but does not provide an object model or a computation¬ 
ally complete language like Smalltalk. Consequently, to 
execute any complex business or application logic, much 
data must be transferred to the client Smalltalk to be 
turned into objects that can execute behavior. As the 
number of client workstations increases, the network 
becomes overloaded. As applications execute more com¬ 
plex business logic, requiring more objects to be trans¬ 
ferred to the client, the client machines need more mem¬ 
ory and processing power. Increasing network bandwidth 
and CPU/memory capability for thousands of client 
workstations can become an expensive proposition. 

There are busi ness drawbacks to the pure client/server 
architecture as well. Transferring sensitive data to the 
client machine to execute application behavior can pose 
a security risk. Client machines are inherently insecure, 
and none of the client Smalltalk systems currently imple¬ 
ment security features in the virtual machine. When the 
business logic is duplicated across thousands of clients, 
maintenance is expensive, and this discourages frequent 
updates to the application. The logic and algorithms 
implemented within busi ness objects are a strategic asset 
to the company and should be a shared resource under 
centralized control. For example, consider the algorithm 
by which a portfolio management application distributes 
a customer's funds among stocks with different risks. The 
better that the application can evaluate market condi¬ 
tions and risk, the better the rate of return. The applica¬ 
tion's risk assessment algorithm needs to be shared by 
multiple clients, may need to be updated frequently 
based upon new strategies, and needs to be protected by 
theft from competitors. 


January 1996 





GETTING REAL 


To overcome the drawbacks of the client/server archi¬ 
tecture, the 3-tier model has emerged.The 3-tier architec¬ 
ture is an evolution of the client/server architecture that 
defines a middle tier, called an application server, 
between multiple client workstations and the data server 
(a relational or legacy database). For a more complete 
description of the 3-tier architecture, see Lozinski. 2 The 
middle tier is where shared business objects are imple¬ 
mented in multi-user Smalltalk.Thisarchitecturereduces 
the amount of data transmitted to the client, because 
business logic can be executed in Smalltalk on the middle 
tier rather than transmitted to the client for execution. 
With this architecture, only a singly high-bandwidth con¬ 
nection from each legacy relational database to theappli- 
cation server is needed, and the rela- 
tional-to-object mapping is per- Trx/inntnt 


tional-to-object mapping is per¬ 
formed in one place, and only when 
needed. The SmalItalk objects on the 
middle tier can be thought of as an 


Trying to build a server 
usinga client Smalltalk 


videa model of transactions and concurrency control, and 
provide a class library designed with multi-user access in 
mi nd. The vi rtual machi ne of server Smal Ital k is tuned for 
disk access, and must be able to handle very large objects 
and a very large number of objects. This Smalltalk is tai¬ 
lored to operation on server-class machinesto take advan¬ 
tage of shared memory, asynchronous 10, and raw parti¬ 
tions on disk. Server Smalltalk is built with transaction 
throughput and client communication as chief considera¬ 
tions. Trying to build a server using a client Smalltalk sys¬ 
tem will not provide the performance or functionality 
req u i red f o r I ar ge-sea I e ap p I i cat i o n s. 

By using multi-user Smalltalk as the application server 
in a 3-tier architecture, developers can implement shared 

business objects with the same lan- 

Id 3 Server 9 uage used to build client applica¬ 
tions. This enables developers to 

Smalltalk move behavior easily from the client 

. * to the server, an activity called appli- 
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This allows for easier integration of 
legacy data, live data feeds, or other 
external data sources into Smalltalk 
applications because each client 
only sees objects in the application 


requ i red for la rge- sea I e 

applications. 


tioning issues. With a common 
object model on both the client and 
the application server, objects do not 
need to be transformed from one 
form to another. Because the same 


server. Clients do not have to know where the server 
objects came from, and are i nsulated from changes to the 
source of these objects. 

Having the shared Smalltalk business objects in the 
middle tier also provides a central point of control for 
updating business logic, defining security policy, and pro¬ 
viding fault tolerance of important objects. In the previ¬ 
ous example, the risk assessment algorithm of the portfo¬ 
lio management application should be implemented as 
functionality provided by a business object. This business 
object is available to clients through a message interface, 
but the implementation of the business object is located 
on the server. The methods that implement the algorithm 
can be updated in one place, and new implementations 
can be made available to clients immediately (after ade¬ 
quate testi ng, of course). The server Smalltalk objects de¬ 
fine security policy so that only certain clients, say, those 
who have paid to use this service, are allowed to execute 
the risk assessment methods. Finally, the server Smalltalk 
provides a central repository of objects that can be backed 
up to tape for archival purposes or recover from hardware 
failure. 

Because of the different roles played by client applica¬ 
tions and the application server in the 3-tier model, the 
requirements for server Smalltalk are quite different than 
those of cl i ent Smal Ital k systems. Cl i ent Smal Ital ks operate 
in a single-user environment. They provide an extensive 
GUI and graphics class library, and are integrated with the 
wi ndowi ng envi ronment of the cl i ent workstation. The vi r- 
tual machines of client Smalltalks are tuned for virtual 
memory access. A Smalltalk on the server, on the other 
hand, operates in a multi-user environment. It must pro¬ 


code can execute in either the client or the application 
server, the developer can initially build the application 
enti rely on the cl ient, then move porti ons of it to the serv¬ 
er as needed. This might be done to share objects, opti¬ 
mize performance, enforce security, or backup important 
data. In addition, these partitioning decisions are easily 
changed as new hardware or software is added to the sys¬ 
tem. Having a common object model and language 
between the client and the server makes the repartition¬ 
ing of an application much simpler, since there is little if 
any code to rewrite. 

When partitioning an application, how does a develop¬ 
er determine where certain objects should reside, i.e, in 
the cl ient or i n the server? Here are some general rules-of- 
thumb to help in this process. The following kinds of 
objects belong on the server: business objects, sensitive 
objects requiring security, large collections of objects 
requiring optimized query capability, objects requiring 
shared access, objects requiringfault tolerance, and “gate¬ 
way" objects (i.e., objects that provide a view of raw data 
on the data server). The following kinds of objects belong 
on the client: window or GUI objects, application-specific 
objects, and "view" objects (i.e., objects that provide a view 
of a server object). My next column will discuss the imple¬ 
mentation techniques for application partitioning. M 
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